Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add service interface to control hardware lifecycle #559

Closed

Conversation

destogl
Copy link
Member

@destogl destogl commented Oct 19, 2021

This PR adds lifecycle management of hardware through services of CM and additional logic to RM to support lifecycle.

@bmagyar: should we delete individual services like "configure_hardware" and leave only. "set_hardware_component_state"?

NOTE: This PR is replaced with multiple follow-ups, but it should stay open until everything is merged because it provides a fully-functional version.

@destogl destogl force-pushed the services-for-hardware-lifecycle branch from bbf2f64 to a14d222 Compare October 25, 2021 06:40
@destogl destogl force-pushed the services-for-hardware-lifecycle branch from 7a22f68 to 58d5cf8 Compare November 3, 2021 16:12
@bmagyar bmagyar added the rolling label Nov 3, 2021
@destogl destogl requested a review from bmagyar November 29, 2021 15:41
Copy link
Member

@bmagyar bmagyar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too much.
Too many lines of code.
Too many things in one PR: new services and overhaul of resource manager to support special movement interfaces.

Let's work out how to split this PR, I'd really hate to see this work wasted but I am not feeling good about this amount of changes in a single PR.

  • You have a huge surface for conflicts
  • It takes a long time to review the code
  • Had to take breaks during review to avoid brain meltdown

Which does not leave me with a good feeling regarding the quality of my review.

Here's a list of PRs I propose:

  • controller_manager_msgs, add new service interfaces with an empty implementation and no tests
  • API changes for init/configure/hardware component info
  • misc changes that shouldn't affect things, aka extending the implementations of
    • test_actuator
    • test_generic_system
    • test_system
  • functional tests and hardware lifecycle management implementation + docs
  • "movement interface"-related changes, once we figure out what we actually envision there


std::vector<std::string> autoconfigure_components = {""};
get_parameter("autoconfigure_components", autoconfigure_components);
rclcpp_lifecycle::State inactive_state(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
rclcpp_lifecycle::State inactive_state(
const rclcpp_lifecycle::State inactive_state(

why do we even have to write constants like this? there should be some global consts available like rclcpp_lifecycle::State::Inactive

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the upstream library does not defines standard states fully, at least not with the ID or names. We could create defines for this or should we directly try to add this into rclcpp?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it is not possible to set this const because of the underlying logic where no copy of state is done but in place changes are added if ID is not provided... Will comment more in corresponding PR.

controller_manager/src/controller_manager.cpp Outdated Show resolved Hide resolved
{{false, false, false, false}, {false, false, false, false, false, false, false}}, // system
}));

// auto test_controller = std::make_shared<test_controller::TestController>();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please either fix or remove this 100 lines of commented code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are missing here test where controllers are used. This was there as a reminder. Now I have this comment which should stay unresolved until we fix this or open an issue.

controller_manager_msgs/msg/HardwareComponentsState.msg Outdated Show resolved Hide resolved
controller_manager_msgs/srv/ListHardwareComponents.srv Outdated Show resolved Hide resolved
EXPECT_NO_THROW(rm.claim_state_interface("external_joint/external_state_interface"));
EXPECT_NO_THROW(rm.claim_command_interface("external_joint/external_command_interface"));
// TODO(destogl): repair this test!
// It fails because interfaces are not in available lists
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so... do we repair or remove it? follow-up issue? fix now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will check

#define COMPONENT_NAME_COMPARE_INV \
[&](const auto & component) { return component.get_name() == component_name; }

#define MOVEMENT_INTERFACES_COMPARE \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why a define on these and not a simple using or just assigning the lambda toa const var?

Copy link
Member Author

@destogl destogl Dec 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because the lambda is outside of class and I would like to have access to the current context "[&]". Will check if there is something better to do here. Although I don't think so.

// check if interface is non-movement interface
if (
std::find_if(
MOVEMENT_INTERFACES.begin(), MOVEMENT_INTERFACES.end(), MOVEMENT_INTERFACES_COMPARE) ==
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm really not happy about us creating/maintaining a standard set of movement interfaces that is handled specially.
The default should always be movement interfaces. How hardware components handle/allow for non-movement interfaces should be designed carefully and not in this PR. I'm sorry but I think the best option at this point is to remove everything related to movement interfaces from this PR and we should discuss the design for this instead. This is way too much code IMO to properly assess and maintain every behaviour of this without a design.


if (result)
{
// TODO(destogl): change this - deimport all things if there is there are interfaces there
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to be blunt but no. I'm not going to add more comments to this file.
At this point this file has way too many TODOs, we should not leave holes and doubts and todos in any feature implementation. All in all, there should be less code in a PR.

@destogl destogl marked this pull request as draft December 1, 2021 11:35
Add HardwareComponentInfo structure in resource manager.

Use constants for HW parameters in tests of resource_manager.

Add list hardware components in CM to get details about them and check their status.

Use clear name for 'guard' and move release cmd itfs for better readability.

RM: Add lock for accesing maps with stored interfaces.

Separate hardware components-related services after controllers-related services.

Add service for activate/deactive hardware components.

Add activation and deactivation through ResourceStorage. This helps to manage available command interfaces.
…only 'set_hardware_component_state' service.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants